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1 Prelude 

The story of the first Unix port begins with a letter 
I received in April 1976 from Professor Juris Rein- 
felds, head of the newly created Computing Science 
Department at the University of Wollongong, Aus- 
tralia. At the time I was a fledgling systems pro- 
grammer at SDL, an Ottawa computer service bu- 
reau which provided a remote batch and timeshar- 
ing service on large IBM mainframes for clients in 
Canada and the U.S. I was preparing to join Juris 
later that year as the department’s second member 
of staff, to set up and run a laboratory for software 
teaching and research. 

Juris’s idea of creating an interactive software lab- 
oratory, using timeshared terminals connected to a 
departmental minicomputer, was a progressive one 
for the time. The usual experience for students in 
computing was to queue up at a university com- 
puter centre to submit their programs and data on 
punched cards, and return some hours later to col- 
lect the printed output. Being constrained to two 
or three attempts per day at compiling and running 
a program may have encouraged a more disciplined 
approach to programming than is common nowa- 
days, but it strictly limited the size of projects which 
students could be expected to tackle, and made it 
difficult to teach computing as an experimental sci- 
ence. 

The plan had been to buy a DEC PDP-11 mini- 
computer to run Unix, a novel operating system 
from Bell Labs which was acquiring a cult follow- 
ing at universities around the world. Juris was im- 
pressed by the positive experience of the nearby Uni- 
versity of New South Wales in Sydney, where Unix 
was used enthusiastically in programming courses as 
well as being itself an object of study in an Op- 
erating Systems course taught by John Lions. Ju- 
ris had sent me a copy of Ritchie and Thompson’s 
1974 CACM paper The UNIX Time-Sharing Sys- 


tem, which I found tremendously exciting. After the 
dispiriting experience of trying to use (and debug) 
early versions of IBM’s TSO timesharing system, the 
simplicity and elegant minimalism of Unix seemed a 
brave new world indeed. 

But Juris’s letter brought a disappointment: the 
price of a PDP-11 was out of reach. Instead, he 
wrote, “unless you voice your objections loudly we 
will probably have an Interdata 7/32 with 10Mbyte 
disk and 192kbyte core as our lab computer... Since 
Interdata assembler is like IBM’s it should be to your 
liking.” As Unix was a PDP-11 operating system, 
no PDP-11 meant no Unix; we would have to build 
our software laboratory using Interdata’s own OS/32 
operating system. 


2 The Interdata 7/32 

I began work at Wollongong, and soon afterwards 
the Interdata minicomputer was installed: a 32-bit 
machine with a peak execution speed of somewhat 
less than 1 million instructions per second, along 
with seven “glass teletype” terminals, and a daisy- 
wheel typewriter which served as both system con- 
sole and printer. 

It did not take long to realise that OS/32 was not 
going to help us to build the kind of interactive sys- 
tem we wanted. Although it was a multi-tasking 
system, able to execute several programs at once, it 
could not really be considered to be multi-user or 
even timesharing in the usual sense. The terminals 
were strictly passive peripheral devices: you could 
run a program using a specific terminal for input and 
output, but programs (including system utilities like 
the text editor and compiler) could only be started 
from the central system console. If something went 
wrong with a program, the error messages would 
appear only on the system console. There was no 
concept of user names or logging in, no file protec- 



tion of any kind, and a single linear directory of files 
on each disk device — a recipe for confusion with 
thirty students all wanting to call their first program 
LESS0N1.BAS. 

Clearly something had to be done before the Inter- 
data would be usable in a student environment. As 
an emergency measure, I cobbled together a proto- 
timesharing system to run on top of OS/32, which 
I modestly named MOTH (My Own Terminal Han- 
dler). Essentially this was a simple multi-user shell, 
which would prompt for a user login at each termi- 
nal, and then read and execute simple commands 
on the user’s behalf, with input and output auto- 
matically directed to the user’s terminal. (I can’t 
recall whether I succeeded in redirecting error mes- 
sages as well.) Some measure of file protection was 
obtained by intercepting system calls from user pro- 
grams, transforming create and open requests to 
make file names unique to each user. There was 
also a simple (voluntary) queuing mechanism which 
could be used to request exclusive use of the console 
printer before sending output there. 

With MOTH in place, the first programming class 
were able to use the lab for their assignments. But 
the service was far from ideal. MOTH’s control 
was not complete: for example, a program which 
entered an infinite loop (not uncommon in student 
programs), could not be interrupted but would have 
to be cancelled from the system console. OS/32 at 
that time had only a primitive memory allocation 
scheme with fixed-size partitions to share our 192 
kilobytes of memory among seven users, with no ca- 
pability of swapping to disk — it was very cramped. 
Among other quirks, the Interdata would crash in- 
stantly if the system console was taken offline. Since 
the console was our only hardcopy device, this hap- 
pened frequently as students attempted to eject a 
page to remove their printout. 

As our frustration with the OS/32 environment 
grew, Unix looked more and more attractive. Could 
we possibly return to the original plan of using Unix, 
even without a PDP-11? Why not attempt to make 
Unix run on the Interdata? 

In the case of a typical computer manufacturer’s 
operating system, the idea of portability to a new 
machine would have been preposterous. Conven- 
tionally operating systems were written in assembly 
language for a specific machine, exploiting low-level 
details of the hardware architecture which were of- 
ten exposed to the user. For example in OS/360, 
disk files had to be allocated by the user in units 
of tracks and cylinders, and for efficient access one 
could write “channel programs” to be executed di- 
rectly by the autonomous hardware which controlled 


the disks. 

But Unix appeared very different. It was writ- 
ten in C, a (fairly) high level language for which 
compilers already existed for other machines besides 
the PDP-11. Also, Unix’s device-independent in- 
put/output model presented a simplified and ab- 
stract view of the underlying hardware, which sug- 
gested machine independence as well. A Unix pro- 
gram writes a string of bytes onto a disk file or a 
magnetic tape or a terminal screen using exactly 
the same simple system call; it should be possible 
to write to an Interdata disk or a PDP-11 disk with 
equal indifference. 

There seemed to be no reason in principle why 
Unix could not be adapted to a different machine. So 
in late 1976 the University of Wollongong ordered a 
source code licence for Unix (6th Edition), and I took 
on the project of making it run on the Interdata. 

3 Porting the C Compiler 

As most of the Unix kernel and nearly all the com- 
mands and utilities were written in C, the first task 
was to produce a C compiler for the 7/32. The ob- 
vious starting point was Dennis Ritchie’s PDP-11 
C compiler, which was itself written in C. I spent 
a few weeks learning the C language by reading a 
printed copy of the compiler source, and unravel- 
ling its structure. There was no internal documen- 
tation and the comments were sparse, but the clear 
and concise style made it quite easy to find one’s 
way around. The compiler was in two sections: a 
syntactic front end which was fairly machine inde- 
pendent, and a code generating back end which for- 
tunately was mostly table driven. I devised a new 
set of tables with code generation templates for the 
Interdata’s instruction set, and wrote new versions 
of routines which performed storage layout, analysis 
of addressing modes, and other machine dependent 
functions. 

I now had (I believed) an Interdata C compiler in 
C source code form, but I needed a running Interdata 
C compiler before I could compile it. This seeming 
paradox appears whenever a compiler is written in 
the language which it is meant to compile, and its 
solution is known as bootstrapping (a term which 
refers to lifting oneself up by one’s own bootstraps). 
In this case I planned a half bootstrap, involving a 
second computer: I would use the PDP-11 C com- 
piler running on a Unix machine at the University of 
New South Wales, to compile my Interdata C com- 
piler. 

On December 14 1976, I made the 80 kilome- 



tre journey from Wollongong to Sydney with the 
proposed changes to the C compiler on a deck of 
punched cards, and spent two days editing, compil- 
ing and debugging. This was my first actual expe- 
rience as a user of Unix, but with some guidance 
from local gurus Peter Ivanov and Ian Johnstone, 
I soon felt at home. I quickly learned about the 
Unix principle of “trusting users to know what they 
are doing” , when I mistyped a filename and inadver- 
tently deleted several hours’ work. But by Decem- 
ber 16 the compiler was able to translate a handful 
of short test programs into what looked like correct 
Interdata assembly language. Using the compiler to 
translate its own source code then resulted in many 
thousands of lines of assembly code, which I copied 
onto a magnetic tape to take back to Wollongong. 

At this point there was a logistical problem: our 
7/32 had no tape drive. The Wollongong Univer- 
sity computer centre had a Univac 1106 mainframe 
with a tape drive, but that was not compatible with 
PDP-11 tapes. Fortunately the Sydney office of In- 
terdata knew of a client who could do tape conver- 
sions. So the translated compiler was copied there 
to a Univac-compatible tape to be taken to Wollon- 
gong, where it was loaded onto the computer centre’s 
1106, transmitted to an Interdata 8/16 (a smaller In- 
terdata machine which was used as a front end com- 
munication processor for the Univac) and copied to 
a 5 megabyte removable disk pack which was carried 
upstairs and loaded onto the Computing Science De- 
partment’s 7/32. 

The assembly language version of the C compiler 
could now be run through the Interdata assembler to 
produce an executable program. Well, that was the 
theory: in fact, what it produced was pages of as- 
sembler syntax error messages. The compiler’s own 
source code contained many new C constructs which 
my trivial test programs had not exercised, so there 
were still mistakes in the code generator. Another 
week’s work on the compiler source followed by a 
second trip to Sydney on December 22 for cross- 
compilation resulted in a new tape full of assembly 
language which was brought back to Wollongong via 
the same tortuous route as before — and this time 
it passed successfully through the assembler. 

One further thing was needed. Because the C 
compiler was originally a Unix program it made use 
of Unix system calls to perform input/output and 
memory allocation. While I was working on the com- 
piler, a library of OS/32 routines to emulate some 
basic Unix system calls (open, close, read, write, 
malloc, and a few others) was being written by Ross 
Nealon, a Wollongong computing student. (Years 
later, Ross took over my place in the department 


when I left Wollongong. He died of cancer, tragi- 
cally young, in 1988.) 

Combining the assembled compiler with Ross’s 
Unix compatibility library gave us, at last, an In- 
terdata C compiler running on the 7/32. It was still 
far from correct, but it could now be maintained on 
our own machine without further trips to Sydney. 
Over the Christmas break I continued testing and 
correcting the compiler. Each time I made a change 
to the assembly language code, I would also make the 
corresponding change in the C source, which when 
eventually compiled would generate exactly the as- 
sembly source which I had just written by hand. 

After many iterations, on January 5 1977 the com- 
piler could successfully compile itself, producing as- 
sembly output identical to the running compiler. 

4 Unix Tools on OS/32 

The C compiler had been moved by a half bootstrap 
procedure, with an initial cross-compilation on an- 
other machine. Had a PDP-11 been available in Wol- 
longong, I would doubtless have carried out a simil ar 
half bootstrap of the operating system, using the ex- 
isting Unix system as a development environment to 
maintain and cross-compile a kernel, for download- 
ing and testing on the 7/32. But if a PDP-11 had 
been available, I would not be doing the port in the 
first place! The 80 kilometres separating us from the 
nearest PDP-11 seemed to mandate a full bootstrap 
of the operating system, performing all the develop- 
ment on the target machine itself. 

Before starting on the kernel, it seemed worth- 
while to get some of the Unix development tools 
working on the Interdata. The system call emulation 
library, which enabled the Unix C compiler to run on 
OS/32, was extended a bit to support other simple 
Unix programs such as the editor ed and file manip- 
ulation and comparison commands. Having these 
available would be a significant aid to productiv- 
ity in comparison with the existing Interdata tools. 
(The standard OS/32 text editor, for example, was 
only able to move sequentially through a file in one 
direction; after examining or modifying a line, one 
could not move to an earlier line of the file without 
exiting from the editor and beginning again.) 

Porting Unix tools to the Interdata was a way 
of exercising more of the C compiler and increas- 
ing confidence in its reliability, and helped to point 
out compatibility problems in C semantics between 
the PDP-11 and Interdata. Although in theory a 
user level C program can be entirely machine inde- 
pendent, in the 6th Edition system rather a lot of 



shortcuts had been taken, with assumed knowledge 
of properties of the PDP-11 which failed on the In- 
terdata. The most common of these were word size, 
the order of bytes within words, and sign extension 
of characters. I learned to be suspicious of any oc- 
currence of the number 2 in a C program — more 
often than not, it really meant sizeof(int) which 
on the 7/32 should be 4. 

5 The Unix Kernel on OS/32 

An operating system like Unix can be decomposed 
into three layers. At the top is the interface de- 
fined by the repertoire of system calls which provide 
operating system services to user programs. In the 
middle are the mechanisms which implement these 
services and manage the sharing of resources among 
processes and users of the system. In Unix this layer 
is largely hardware independent; for example, all di- 
rect access devices are treated in an abstract way as 
indexed collections of fixed-size blocks. At the bot- 
tom are device drivers, interrupt handlers and other 
low-level routines which deal with the idiosyncrasies 
of actual hardware behaviour, and support the sim- 
pler view of idealised hardware used by the layer 
above. 

Because each layer depends on the one below, it 
would appear that a new implementation of Unix 
would need to be built from the bottom up. But the 
7/32 was not a bare machine: it already had an op- 
erating system, and in a sense the top layer of Unix 
was already working above OS/32 in the form of our 
library of emulated system calls. There was a com- 
pelling attraction to the idea of continuing from the 
top down, beginning with the easier task of porting 
and testing the middle layer over an idealised hard- 
ware interface provided by the facilities of OS/32, 
and leaving the complexities of the real hardware 
until the last. 

Here I was influenced by my experience at SDL, 
where IBM’s VM/370 operating system had been 
used to test multiple versions of OS/360 concur- 
rently on the same machine. VM used the IBM 370 
paging facilities to divide the computer into several 
disjoint virtual machines, each able to run its own 
operating system with the illusion of having com- 
plete control of the real hardware. Execution of the 
virtual machines was timeshared, with privileged in- 
structions being intercepted and emulated by the 
VM kernel. The virtualisation was so complete that 
a VM virtual machine could be used to run another 
instance of VM itself. 

OS/32 was not quite as sophisticated as VM/370, 


but it did have some useful facilities for real-time 
programming which could be exploited to build a 
kind of virtual machine environment. Like the 370, 
the Interdata had a Program Status Word (PSW) 
with an instruction pointer and control bits for en- 
abling and disabling interrupts and memory protec- 
tion and relocation. An interrupt or system call in- 
struction would cause the old PSW to be stored in a 
fixed location in low memory, and a new PSW (typ- 
ically with interrupts disabled) to be loaded from a 
table indexed by the type of interrupt. 

Under OS/32, each program’s address space be- 
gan with a reserved area called the UDL, contain- 
ing system information about the running program. 
This included things like pointers to open files, and 
a Task Status Word (TSW) which was analogous to 
the PSW. If a program requested an asynchronous 
input/output operation, the operating system would 
signal its completion by a TSW exchange, loading a 
new TSW and instruction pointer from a table in 
the UDL which was analogous to the hardware in- 
terrupt table in low memory. An OS/32 program 
which was declared at link time to be an E-task (ex- 
ecutive task) had extra privileges, and could define 
its own system calls by specifying that certain sys- 
tem call instructions would load a new TSW from 
the program’s own UDL instead of the kernel’s table. 

These mechanisms provided most of what was 
needed to emulate the lowest layer of Unix — asyn- 
chronous device I/O, process switching, interrupt 
handling, and system calls to switch between user 
and kernel mode — by manipulating TSWs within 
a single OS/32 partition. The missing mechanism 
was control over memory management, which I had 
to supply by trickery. As an E-task, the virtual Unix 
kernel had access to the 7/32 ’s memory management 
registers, so it was able to perform its own address 
relocation, swapping multiple Unix processes in and 
out of its memory partition while maintaining the 
illusion of being a single OS/32 process. 

Using this simple virtual machine environment on 
OS/32, porting the top and middle layers of Unix 
proved fairly straightforward. Nearly all the changes 
required were due to trivial word size and byte or- 
der problems — the program logic remained almost 
unaltered. Developing and testing a virtual version 
of Unix on OS/32 had practical advantages. There 
was no need for exclusive use of the machine; us- 
ing MOTH the system could be used by students at 
the same time as my kernel testing. And the OS/32 
interactive debugger was available for breakpointing 
and single-stepping through the Unix kernel just like 
any other program. 



6 Unix Stands Alone 

By February, it was possible to log in to a terminal 
assigned to the virtual Unix and run (very slowly) 
a Unix program. One of the 7/32’s two 5 megabyte 
disk drives was initialised as a Unix file system, by 
writing a data-only assembly program whose struc- 
ture was the image of an empty file system, assem- 
bling it, and copying the binary result to the disk. 
The file system was gradually populated with Unix 
commands, each one being compiled and assembled 
under OS/32, converted from OS/32 object to Unix 
a. out format, and moved to the Unix disk. At last 
it was time to perform the conjuring trick of whip- 
ping OS/32 out from underneath, leaving Unix to 
stand on its own. 

Writing device drivers for the Interdata peripher- 
als (disk drive, serial interface, clock) was challeng- 
ing as expected: real hardware, unlike the virtual 
kind, is always full of surprises. I was able to use 
PDP-11 drivers as a pattern, but the Interdata archi- 
tecture was rather more complex. Communicating 
to the disk drive, for example, involved a disk con- 
troller and DMA channel as well as the drive itself, 
all needing to be programmed separately and in the 
right order, and all generating separate interrupts 
(or not, depending on timing conditions). Fortu- 
nately the top-down approach meant that I was not 
trying to test drivers and interrupt handlers on a 
bare machine: I had all the rest of Unix, already 
running and stable, to use as a test bed. On April 
28, Unix was running in full control of the 7/32. 

Of course, the first successful “Hello, world” is 
not the end of the story. Until this point the C 
compiler was still running on OS/32, because the 
OS/32 assembler was needed to assemble its output. 
When I wrote a new Interdata assembler for Unix 
(in C), I was gratified to find that it was smaller and 
much faster than Interdata’s own assembler (written 
in assembly language) — a victory for the principle 
of systems programming in a high level language. 
Many other Unix commands and utilities needed 
compiling and testing, and most had the odd trivial 
PDP-11 dependency to be corrected. Another three 
months of work were required until 25 July 1977, 
when OS/32 was retired and Unix formally became 
the production system on the Wollongong 7/32. 


erating system was portable. In fact there was a 
surprise on both sides: a team at Bell Labs was in 
the midst of doing their own port of Unix to an In- 
terdata 8/32 (a slightly more powerful 32-bit mini- 
computer). They had begun work at the beginning 
of 1977 in anticipation of the delivery of their ma- 
chine in April, and had a kernel working by June — 
less than two months after the Wollongong kernel 
first ran on the bare 7/32. 

The Bell Labs Interdata port was never released 
to the public, but it became the basis for the 7th 
Edition of Unix, which was specifically engineered 
to be portable (with Steve Johnson’s new portable 
compiler, and a much more disciplined approach to 
data typing in C). When the PDP-11 version of 
the 7th Edition became available, the University of 
Wollongong ordered a copy, and I ported that to 
the Interdata, with some assistance from Robert Elz 
at the University of Melbourne who had been us- 
ing the Wollongong 6th Edition system on an 8/32. 
The project was somewhat easier the second time 
around, but there was still a lot of work because the 
kernel had already begin to grow bigger and more 
complex, and there were many new commands. 

The appearance of the 7th Edition of Unix be- 
gan a trickle and then a flood of porting projects in 
many places to machines of all kinds; by the early 
1980’s there were at least three companies making a 
full-time business of porting Unix. By the 1990’s no 
computer, from micro to mainframe, could be con- 
sidered to be a serious machine if it wasn’t able to 
run some form of Unix. Now, twenty-one years after 
the first port, it’s difficult to believe that there once 
was a time when operating system portability was 
an audacious idea. 


7 The 7th Edition 

When Unix first began to run as a stand-alone sys- 
tem on the Interdata we contacted Bell Labs, ex- 
pecting them to be surprised to hear that their op- 



